Software development is typically performed as group projects. A subject software system is developed through design efforts, test efforts, implementation efforts and maintenance efforts. There may be different groups and different group members participating in each of these efforts. Throughout these efforts and among the work group members, various modeling and other development tools are used for increased communication and consistency in developing the subject software system. A software configuration management system is one such tool. Software configuration management systems allow teams of users (software developer/engineer) to work with artifacts of a subject software system.
A software artifact is a persistent representation of an aspect of a software system. Common examples of software artifacts are files and directories containing the source code of a software system, but other examples of artifacts include requirements, end-user documentation, system models, and system tests. A significant state of a software artifact is saved as a version of that artifacts and the sets of versions of a given artifact define the history of that artifact.
A software configuration is a set of software artifact versions, where only one version of a given artifact is selected by a given software configuration. A change-set identifies a logical change to a configuration, and consists of a set of one or more changes to one or more artifacts. An alternative characterization of a software configuration is that it consists of the set of change-sets that have resulted in that configuration.
A change-set is the mechanism that allows a software developer to determine what logical changes are in a given software configuration. Although in general a single change-set can include changes to multiple artifacts in a configuration (if multiple artifacts had to be modified to perform the logical change captured by that change-set), for the purposes of this invention, it is sufficient to consider the effect of a change-set on a single artifact in the configuration.
The standard data structure for capturing the changes to a software artifact is an artifact version history, which consists of a set of versions of that software artifact, connected by arcs that represent the change that was performed to produce one version of the artifact from a previous version of the artifact (or in the case of a merge, from multiple previous versions of the artifact).
For example in FIG. 1, an initial version 100 (version 0) of the software artifact is created by the change labeled 0. Version 1 (at node 111) is created by performing change 1 on version 0 (at node 100), version 2 (node 112) is created by performing change 2 on version 0 (node 100). Version 3 (node 113) is created by performing change 3 on version 1 (node 111), and version 4 (node 114) is created by performing change 4 on version 2 (node 112).
Commonly, a user will want to logically merge all the changes from one version into another version. An example of this appears in FIG. 2, where version 5 (node 115)is the result of merging all of the changes that produced node 114 version 4 (i.e., change 0, change 2, and change 4) into version 3 (node 113).
The result is that version 5 (node 115) logically contains the union of all of the changes 0, 1. 3 that produced version 3 (at node 113) with all of the changes 0, 2, 4 that produced version 4 (at node 114), in addition to the change (change 5) needed to resolve any conflicts between those changes.
To determine all of the logical changes that are contained by a given version, the configuration management system can simply enumerate the change that produced that version and all of the changes that produced a predecessor of an enumerated version. For example, the changes in version 3 (at 113) are change 3, change 1, and change 0, while the changes in version 5 (at 115) are change 5, change 3, change 4, change 1, change 2, and change 0.
In some cases, the user only wants to merge a particular logical change, and not all of the changes that have produced the version containing that logical change. For example, suppose in FIG. 2 that the user is interested in merging just change 4 (and not change 2) into version 3 (node 113). This is called a “selective merge”.
In other cases, the user doesn't want to merge a set of changes into a given version, but instead wants to remove or undo a change that is currently in a given version. For example suppose the user is interested in removing change 1 from version 3 (node 113). This is called a “subtractive merge”.
A problem that is introduced by a subtractive merge is how to handle the case where a user wants to merge all of the changes from a source version into a given target version, and the target version already contains a particular change, but that change has been explicitly removed from the source version by a subtractive merge. Should the result of the merge of the given source version into the given target version contain that change or not?
A mechanism is required to represent both selective and subtractive merges in an artifact version history, to detect when a merge produces an ambiguity as to whether a given change should be kept or omitted from the merge, and to represent how that ambiguity has been resolved. This mechanism must allow for efficient computation of what logical changes arc present in any given version in an artifact version history.